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METHODS AND SYSTEMS FOR DETERMINING NETWORK TOPOLOGY 

Technical Field of Invention 

The present invention refers to methods and systems 
for determining a reconf igurable topology of a network of 
nodes having ports that are interconnected via unidirec- 
5 tional connections. The invention is especially applic- 
able is the context of networks wherin several different 
kinds of topologies are allowed within the network. 

Background of the Invention 

10 A communication network is a data processing system 

that includes a plurality of interconnected components, 
or nodes, such as work stations, phones, data storage 
devices, printers, servers, switches, routers, hubs, etc. 
The ports of the nodes are interconnected via connections 

15 and communicate by transmitting and receiving messages to 
or from ports on other nodes on such connections. 

In order for a node to know how a selected destina- 
tion in the network is reached, for example in which 
direction to send a message or set up a channel destined 

20 for an intended receiver, there is a need for the nodes 
to know the topology, sometimes also referred to as 
architecture or configuration, of the network, at least 
of a local portion thereof. Such information can either 
be provided to one or more nodes of the network using 

25 manual configuration, or it can be provided using diffe- 
rent kinds of automized ways of having the nodes of the 
network discovering the network topology on thier own. 

One way of providing each node with information on 
the network topology is to use a centralized scheme in 

3 0 which a central source will provide a map of the network 
to all other nodes of the network, for example as descri- 
bed in U.S. Pat. No. 5,654,958 (Natarajan) . A disadvan- 
tage of this solution is that each change in the network 
topology has to be brought to the attention of the cent- 

3 5 ral source and has to be addressed by the central source 
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if said change is to come to the other nodes attention, 
automatically adding signaling overhead between the cent- 
ral source and the network nodes. Also, if the central 
source is down, updating of network topology is tempora- 
5 rily rendered impossible. 

Another way of providing each node with information 
about the network topology is to use a distributed scheme 
in which messages, containing information pertaining to 
the local network topology, are exchanged between the 

10 nodes of the network. Based upon received topology messa- 
ges, each node will generate and maintain its own map of 
the network, or at least of a local portion thereof. 

U.S. Pat. No. 5,682,479 (Newhall et al . ) describes 
an example of such a solution, wherein each network node 

15 is arranged to transmit vector-routed packets cross the 
network in various specified direction, each packet 
gathering information about the network topology along 
its way. The packets are then returned to the originating 
node with the gathered information. 

20 U.S. Pat. No. US 5,506,838 (Flanagan) describes a 

similar solution wherein so-called discovery packets are 
forwarded from link to link within the network, thereby 
informing the network nodes on network topology. 

As another example, U.S. Pat. No. 5,732,086 (Son- 

2 5 Chyay et al . ) describes a method for determining a recon- 

figurable topology of a network by each node exchanging 
messages with its neighbors. 

As another example, UK Patent Application GB 
2,133,952 describes a method for verifying the topology 

3 0 of a network of nodes that are connected in multiple ring 

link topologies. 

A disadvantage with the above-mentioned prior art 
schemes is that they reliy on the limitation that nodes 
in each case are interconnected using a predifined type 
35 of links, for example requiering that the nodes of the 
netowrk are interconnected via bidirectional point-to- 
point connections only or requiering that the nodes of 
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the network are connected via ring links only. Such limi- 
tations has the advantage of simplifying the design of 
each scheme, but also has the negative effect of limiting 
the applicability of the schemes. 
5 In networks in which several different kinds of link 

types may exist, the task of automatically determining 
network topology becomes more difficult. For example in a 
so-called DTM (Dynamic synchronous Transfer Mode) net- 
work, ports are connected via a unidirectional connec- 

10 tions (typically an optical fiber) to form point-to-point 
links (two unidirectional point-to-point connections) , 
single ring links (each formed by one unidirectional ring 
link) , dual ring links (each formed by two unidirectional 
ring links) , or dual bus links (each formed by two uni- 

15 directional bus links) , the latter three link types being 
multi-access shared links. 

An object of the invention is therefore to provide a 
simple distributed scheme for determining network topo- 
logy which allows several kinds of link types to exist in 

20 the network and that does not rely solely on bidirectio- 
nal point-to-point connectivity. 

Yet another object is to provide a scheme wherein 
the amount of messages transmitted within the network in 
order to determine the network topology is kept low. 

25 

Summary of the Invention 

The above-mentioned objects are achieved by the 
invention as expressed in methods and systems according 
to the accompanying claims. 

30 According to the invention, the existence of a loop 

within a network of nodes having ports that are intercon- 
nected via unidirectional connections is determined using 
message forwarding. Information gained by having determi- 
ned the existence of said loop is then distributed to 

3 5 nodes of the network. 

The invention is thus based upon the idea of regar- 
ding the network in terms of network loops (at least when 
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determining network topology) , and to determine topology, 
verify topology, and distribute information related to 
based upon the existence of such loops. 

According to a preferred embodiment, a node of the 
5 network will transmit a message, sometimes referred to 
herein as a topology discovery message or probe message, 
from an output port and will subsequently determine 
reception of a forwarded or reply version of said message 
at an input port, thereby indicating the existence of a 

10 network loop. Furthermore, each node of the network that 
receives a topology discovery message is preferably 
arranged to forward or reply to said message on at least 
one, typically all, of its output ports. 

Preferably, each or at least a plurality of the 

15 nodes of the network will be arranged to transmit and 

detect messages of this kind. Furthermore, preferably all 
nodes of the network will be arranged to forward or reply 
to such messages . 

As is understood from the invention, in most net- 

2 0 works incorporating distributed control functions, even 
those that allow several kinds of link types to exist 
within the same network, a unidirectional connection 
between a first node and a second node will generally 
only form part of a valid link or topology if there 

2 5 exists some kind of communication path from the second 

node back to the first node. In other words, it must be 
possible to in theory draw, following in the direction of 
unidirectional connections / links , a line forming a loop 
from the first node to the second node and back to the 

3 0 first node. 

Having determined the existence of a loop, informa- 
tion pertaining thereto is distributed to nodes of the 
network, typically nodes forming at least part of said 
network loop, but possible also to other nodes of the 
3 5 network, i.e. nodes that do not form part of said loop. 
According to one embodiment, this will include distri- 
buting information as to which nodes, and which ports 
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thereof, that form part of said network loop, wherein 
generation and distribution of such information is pre- 
ferrably performed using message forwarding. According to 
another embodiment, it will include informing a neighbor 
5 node on the existens of a valid connection thereto. 

Ideally, transmission and forwarding/reply using one 
single and comparatively small message will be enough to 
determine the existence of a network loop. Advantageo- 
usly, such a loop will be determined even though the net- 

10 work, and more specifically the loop as such, may compri- 
se a number of point-to-point connections that lack bi- 
directional connectivity, which in some cases would have 
been impossible in prior art. 

According to a preferred embodiment, a node having 

15 two or more outgoing ports, and having not yet been able 
to determine which one of said output ports that is part 
of a specific network loop, is arranged to transmit two 
or more respective messages from respective output ports, 
each message identifying the respective output port 

20 (sometimes referred to herein as "reply ports"), used for 
transmission thereof and thereby enabling subsequent 
determination of which one of said two or more output 
ports of said node that forms part of said network loop. 
For example, the sending of such two or more different 

2 5 messages may be initiated by the reception of a topology 

discovery message (probe message) or may be initiated by 
the sending node itself. 

Expressed in terms of steps performed by nodes of 
the network, a specific example of this embodiment 
30 comprises the steps of: transmitting a message from an 
output port of a first node; receiving said message, as 
such or in a forwarded version, at an input port of a 
second node,- transmitting two or more modified versions 
(forward version or reply version) of said message from 

3 5 respective two or more output ports of said second node, 

each modified version identifying the respective output 
port used for transmission thereof; receiving at least 
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one of said modified versions of said message at said 
first node, thereby identifying which one of said two or 
more output ports that forms part of said network loop; 
and transmitting a message from said first node to said 
second node, said message identifying the output port of 
said second node that forms part of said network loop. 

To be noted, several ports at the second node may 
provide a path back to the sender of the first message. 
For example, if the first node and the second node are 
both connected to the same dual ring link, there will 
exist two return paths from the second node to the first 
node, one along the same unidirectional ring as the out- 
put port that the first message was transmitted from con- 
nection is connected to, and one in the opposite direc- 
tion along the other unidirectional ring. However, if the 
two nodes for example form part of the same single ring 
link or dual bus link, only one port of the second node 
would provide a path back to the originating node (assu- 
ming that no paths over other links are available) . 
0 Also to be noted, the so-determined reply port does 

not necessarily have to be the port that the repying node 
would generally use for transmitting data to the origina- 
ting node. It is merely selected as being one of the 
ports that the replying node may use for sending control 
5 messages upstreams to the originating node, especially 
control messages regarding the probed connection (or 
rather the link that the connection forms part of). 

An advantage of the invention is thus that a first 
node may determine the existence of a valid connection to 
0 second node without knowing in advance what kind of link 
the connection forms part of. Similarly, the second node 
will gain information on the valid connection and is able 
to reply to the first node without knowing in advance how 
to reach the first node nor the exact type of the links 
5 concerned in the message exchange. 

According to another embodiment of the invention, 
link topology messages providing information on which 
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nodes that are connected to a multi-acces link that a 
unidirectional connection forms part of are propagated 
from one node to another on the link, each node using the 
output port /connection that forms part of the link to 
5 reach a downstream node on the link and using a reply 
port (which typically has beed identified using the 
above-mentioned scheme and which may or may not be part 
of the actual link which the topology message pertaing 
to) to reach an upstream node on the link. 

10 According to yet another embodiment, information as 

to which nodes, and preferably also which ports thereof, 
that form part of a determined network is generated using 
message forwarding. For example, each node forwarding or 
replying to a received topology discovery message, or a 

15 forwarded or reply version thereof, may correspondingly 
include information as to the identity of the forwar- 
ding/replying node, and typically also of the output port 
thereof, into said message. The loop information genera- 
ted in such a manner may then be distributed to the nodes 

20 forming said loop, preferably also using message forwar- 
ding. 

As used herein, an interface is generally defined by 
an input port and an output port of a node. When a node 
is connected to a multi-acces ring or bus link, it is 

2 5 connected to the link using the input port and the output 
port of the same interface. Similarly, two connections 
connected to the same interface is generally considered 
herein to form part of the same link, such as a bidirec- 
tional point-to-point link, a unidirectional bus link, or 

30 a unidirectional ring link. To be noted, a unidirectional 
single bus link may generally as such (i.e. if lacking 
any other connectivity) be viewed as forming a invalid 
link, since there is no possibility for a downstream node 
to send a message to an upstream node on the link unless 

35 other connections/ links are added to form an expanded 

topology (for example turning the single bus link into a 
single ring link, a dual bus link) . 
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Although applicable in many types of networks, the 
invention is especially advantageous, for reasons discus- 
sed above, in networks allowing the existence of several 
kind of link types, such as ring, bus, as well as point- 
5 to-point links, such as in a DTM network. More informa- 
tion on DTM networks are found in, for example, "The DTM 
Gigabit Network", Christer Bohm, Per Lindgren, Lars 
Ramfelt, and Peter Sjddin, Journal of High Speed Net- 
works, 3 (2 ): 109-126 , 1994, and "Multi-gigabit networking 

10 based on DTM", Lars Gauffin, Lars Hakansson, and Bjorn 
Pehrson, Computer networks and ISDN Systems, 24(2):119- 
139, April 1992. 

Concluding, the solution of probing the network in 
terms of network loops, determining the existence of such 

15 loops, and distributing topology information pertaining 

thereto to at least one node that forms part of the loop, 
clearly forms an inventive idea involving an inventive 
step . 

The above mentioned and other aspects, features and 
2 0 details of the invention will be more fully understood 
from the following description of exemplifying 
embodiments thereof . 

Brief Description of the Drawings 

2 5 Exemplifying embodiments of the invention will now 

be described in detail with reference to the accompanying 
drawings, wherein: 

Figs, la-lc show networks based on different kinds 
of link types; 

30 Fig. 2 shows a flow chart of a topology discovery 

process according to an embodiment of the invention; 

Figs. 3-5 illustrate how messages are exchange 
between nodes of a network in accordence with the topo- 
logy discovery process shown in Fig. 2; 

3 5 Fig. 6 shows a flow chart of a topology discovery 

process according to another embodiment of the invention; 
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Figs. 7a-7c illustrate how messages are exchange 
between nodes of a network in accordence with the 
exemplifying topology discovery process shown in Fig. 6 ; 

Fig. 8a is a block diagram of components of an 
5 exemplifying network node; and 

Figs. 8b and 8c illustrates topology information 
stored in the memory of the node in Fig. 8a. 

Detailed Description of a Preferred Embodiment 

10 Fig. la-lc illustrate nodes 10, 20 and 30 being 

capable of operating in networks based on different kinds 
of link types. As illustreated, node 10 comprises two 
interfaces, one defined an output port 11 and an input 
port 12 and the other defined by an output port 13 and an 

15 input port 14. Similar interfaces and ports are found on 
nodes 2 0 and 30. 

In Fig. la, the nodes 10, 2 0 and 3 0 are interconnec- 
ted via unidirectional connections 101, 102, 103, and 104 
to form a dual bus link interconnected. 

2 0 Connections 101 and 102 together forms a first uni- 

directional bus interconnecting nodes 10, 20 and 30, node 
10 acting as head end of the bus and node 3 0 acting as 
terminating end thereof. Connections 103 and 104 forms a 
second unidirectional bus also interconnecting nodes 10- 

25 30, node 30 in this case acting as the head end and node 
10 acting as terminating end thereof. Together, the bus 
links formed by connections 101-104 forms a double bus 
link. It is also noted that node 10, connection 101 from 
output port 11 of node 10 to input port 22 of node 20, 

30 node 20, and connection 104 from output port 23 of node 
2 0 to input port 14 of node 10 together may be viewed as 
forming a network loop, as indicated by a semi-circular, 
dotted arrow. Likewise, node 20, connection 102 from node 
2 0 to node 30, node 30, and connection 103 from node 3 0 

35 to node 2 0 together may be viewed as forming another 

network loop 32. The double bus link may thus be viewed 
as being built up by three consecutive network loops 31- 
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33. Likewise, said second double bus link may be said to 
be built up by two consecutive network loops 34 and 35. 

In Fig. lb, the nodes 10, 2 0 and 3 0 are interconnec- 
ted via unidirectional connections 105, 106, and 107 to 
5 form a ring link. In this case, the ring topology may 

thus be viewd as forming one network loop that comprises 
all three nodes, as indicated by the semi-circular dotted 
arrow in the center of the figure. 

As shown in Figs la and lb, when connected to form 
10 multi-access shared links, a node is typically connected 
to the link using the input and output port of one single 
interface . 

As a third example, in Fig. lc, the nodes 10, 20 and 
30 are interconnected via unidirectional to form a row of 

15 two bidirectional point-to-point links, both ports of an 
interface of one node being connected to both ports of an 
interface of another node. However, the connections 
forming a bidirectional point-to-point link may also be 
viewed as together forming small network loops, as 

20 illustrated by the dotted semi-circular arrows. 

A flow chart of a topology discovery process accor- 
ding to an embodiment of the invention will now be 
described with reference to Fig. 2. As is understood, the 
main object of this topology discovery algorithm is to 

25 determine the existence of network loops of the kind 
indicated in Figs, la-lc and to provide information 
related thereto to the nodes that form part of the 
respective network loop. 

With reference to Fig. 2, the topology discovery 

3 0 algorithm comprises a loop detection step S10, a master 
announce step S20, a split-point reduction step S30, a 
loop list build-up step S40, a loop list distribution 
step S50, and a route table computation step S60. 

Each of the steps of Fig. 2 will now be described 

3 5 with reference to an exemplifying network illustrated in 
Figs. 3-5, said network comprising six nodes 10, 20, 30, 
40, 50, and 60. In this example, it is for simlicity 
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assumed that node 10 only has one interface being defined 
by an output port 11 and an input port 12 , and that each 
one of nodes 20, 30, 50, and 60 in similar has one corre- 
sponding interface, wheras node 40 is assumed to comprise 
5 two interfaces, one being defined by output port 41 and 
input port 42 and the other being defined by output port 
43 and input port 44. 

As shown in Figs. 3-5, output port 11 of node 10 is 
connected via a unidirectional connection to input port 

10 22 of node 20, output port 21 of node 20 is connected via 
a unidirectional connection to input port 32 of node 30, 
output port 31 of node 30 is connected via a unidirectio- 
nal connection to input port 42 of node 40, and output 
port 41 of node 40 is connected via a unidirectional 

15 connection to input port 12 of node 10, in all forming a 
first single ring link. Furthermore, output port 43 of 
node 40 is connected via a unidirectional connection to 
input port 52 of node 50, output port 51 of node 5 0 is 
connected via a unidirectional connection to input port 

20 62 of node 60, and output port 61 of node 60 is connected 
via a unidirectional connection to input port 44 of node 
40, in all forming a second single ring link. 

An example of a loop detection step S10 of the topo- 
logy discovery algorithm in Fig. 2 according to the pre- 

25 ferred embodiment of the invention will now be described 
with reference to Fig. 3. During the loop detection step 
S10, the nodes of the network will transmit so called 
probe messages that are used to detect the presence of 
loops in the network topology. A node transmits probe 

30 messages on all output ports that, are not part of 

already determined loops. When a node generates probe 
messages, each message is provided with a unique identi- 
fication identifying the probe message origin, i.e. 
identifying the output port that the message is transmit- 

3 5 ted from, for example the unique MAC address of the out- 
put port. The nodes of the network are in this embodiment 
arranged to forward received probe messages on all output 
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ports. When forwarding a probe message, the content of 
the received probe message is mapped into the transmitted 
message. In other words, the content of the forwarded 
probe message will essentially be a copy of the content 
5 of the received probe message, thus identifying output 
port of the node that originated the probe message. The 
distribution of probe messages is limited by a hop-count 
mechanism that limits the number of hops that a probe 
message is forwarded over. (For simplicity, in the 

10 illustrated example, it is assumed that the number of 

hops that a message is allowed to travel is set to four.) 

When a node receives one of its own probe message 
from another node, it will determine that a loop exists, 
and it will know which one of its input ports and output 

15 ports that forms part of this new loop. The node then 

becomes a so-called build-up master for the new loop and 
continues to the master announce step for the new loop. 

In the example shown in Fig. 3, node 10 transmits a 
probe message PR (11) on its output port 11 to node 20, 

2 0 said probe message identifying the origin of the probe 

message. Node 2 0 then forwards the probe message on out- 
put port 21 to node 30, having incremented the hop-count 
indicated in the probe message by one. Node 3 0 forwards 
the probe message on output port 31 to node 40. Since 
25 node 40 has two output ports, it forwards the probe 

message on output port 41 to node 10 as well as on output 
port 43 to node 50. Node 50 will then forward the probe 
message on output port 51 to node 60. Since the maximum 
number of allowed hops has been reached, node 60 will 

3 0 decide not to forward the probe message. However, at the 

same time, node 10 will have received its own probe 
message from node 40 on input port 12 and will therefore 
determine that a network loop exists and that output port 
11 and input port 12 are part of this new loop. Node 10 
3 5 will then take on the role as build-up master and 
continue to the master announce step. 
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In the master announce step S2 0 of the topology 
discovery algorithm, when a node has determined the 
presence of a new loop using probe messages as described 
with reference to Fig. 3, it will take on the role as 
5 build-up master for the new loop. In order to let other 
nodes learn about the existence of the loop, the build-up 
master will send out a so-called master announce message 
(not shown) on the output port previously identified as 
being part of the new loop. The master announce message 

10 is forwarded by the same rules as the probe messages and 
serves two purposes. The first purpose is to inform other 
nodes about the existence of a new loop and to assign an 
identifier to the new loop, typically being the MAC add- 
ress as mentioned above. This loop identifier is contai- 

15 ned in all subsequent messages concerning the new loop 

and allows several loops to be discovered simultaneously 
without risking mix up of messages referring to different 
new loops. Upon receiving the master announce message, 
the other nodes become so called build-up slaves for the 

.20 new loop and automatically know which of its input ports 
that are part of the loop. The second purpose of the 
master announce message is that it provides a mechanism 
for build-up master arbitration. If two nodes simultane- 
ously receive their own probe messages, they will both 

25 try to take on the role as build-up master. In this pre- 
ferred embodiment, this is resolved by a precedence 
mechanism based on the MAC addresses of the build-up 
masters. If a build-up master receives a master announce 
message (on the input port for which it is currently 

3 0 trying to become build-up master) from a node with a 

higher MAC address, it retreats, at least temporarily, 
and becomes build-up slave instead. If a build-up master 
receives a master announce message from a node with a 
lower MAC address, the master announce message is not 

35 forwarded. 

When the build-up master eventually receives its own 
master announce message, it knows that all other nodes in 
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the new loop have become build-up slaves and that it is 
the only build-up master for the new loop. The build-up 
master then continues to the split-point reduction step. 
An example of the split-point reduction step S3 0 of 
5 the topology discovery algorithm according to the pre- 
ferred embodiment of the invention will now be described 
with reference to Figs. 4a and 4b. A so-called split- 
point node is a node that has two or more connected out- 
put ports, in this case node 40. When a node forwards a 

10 probe message or a master announce message, it must for- 
ward the messages on all its output ports, since it does 
not know which port that is part of the new loop. The 
goal of the split-point reduction step is to determine 
which one of the output ports of the split-point node 

15 that forms part of the new loop. 

The split-point reduction step is started by the 
build-up master, which will send out a so called split- 
point announce message on the output port where it pre- 
viously sent out the probe and master announce messages. 

2 0 The split-point announce message is provided with an 

identifier of the output port that it was sent on. 

Split-point announce messages are forwarded accor- 
ding to the following rule: If the forwarding node has 
only one single output port, or if it already knows which 
25 output port that is part of the new loop (i.e. it has 

already been "resolved" as discussed below) , the split- 
point announce message is forwarded in an unmodified 
version via the correct (or only) output port. Otherwise, 
the node is a considered a split-point node. It then 

3 0 sends out its own new split-point announce messages on 

all its output ports, instead of the received split-point 
announce message. Moreover, each new split-point announce 
message contains an identifier of the output port that it 
was sent on. 

3 5 When the build-up master receives a split-point 

announce message with an identifier for an output port of 
another node, it knows that that output port is part of 
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the new loop. The build-up master informs the split-point 
node about this by transmitting a so-called split-point 
reduce message identifying that output port. Split-point 
reduce messages are forwarded in the same way as probe 
5 and master announce messages. When a split-point node 

receives a split-point reduce message identifying one of 
its output ports, it knows that that port is part of the 
new loop. The split-point has now been resolved, and the 
split-point reduce message need not be forwarded. Conse- 

10 quently, when the next split-point announce message is 
received at the node, it is forwarded unmodified on the 
now determined output port for the new loop. 

Moreover, when a split-point node has been informed 
about which of its output ports that is part of the new 

15 loop, it sends out a so called release branch message on 
all other output ports. This is done to inform build-up 
slaves downstream from those ports that they are not part 
of the loop and they can now remove all protocol state 
regarding the loop and try to establish other loops 

20 instead. 

Directly after sending out a split-point reduce 
message, the build-up master sends out a new split-point 
announce message to find the next split-point node. The 
split-point reduction step thus continues by reducing one 

25 split-point at a time starting from the split-point 
closest to the input port of the build-up master and 
working its way back to the output port of the build-up 
master . 

When the build-up master finally receives one of its 
3 0 own split-point announce messages, it knows that there 
are no more split-points in the loop. All the nodes 
forming part of the loop now knows which of its ports 
that are part of the loop, and all messages regarding the 
new loop is therefore transmitted only to the nodes in- 
3 5 volved in the loop. So far, however, each node only has 
information about its own ports, i.e. no node has comp- 
lete knowledge of all nodes in the new loop (except in 
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very simple topologies) . The build-up master therefore 
continues to the so-called loop list buildup step. 

In the example shown in Figs. 5a and 5b, the build- 
up master node 10 starts by sending out a split-point 
5 announce message SPA (11) on the output port 11 to node 
20. The split-point announce message SPA (11) is provided 
with an identifier of the output port 11 that it was sent 
on. The message SPA (11) is forwarded by nodes 2 0 and 3 0 
to node 40. However, as node 4 0 has two connected output 
10 ports, node 4 0 sends out its own new split-point announce 
messages SPA (41) and SPA (43) on its respective output 
ports, each message identifying the output port that it 
was sent on. When the build-up master node 10 receives 
the message SPA(43) from node 40 in Fig. 5a, it knows 
15 that the identified output port 41 is part of the new 

loop. As shown in Fig. 5b, the master node 10 therefore 
informs the split-point node 40 about this by transmitt- 
ing a split-point reduce message SPR(41) identifying the 
output port 41, said message being transmitted/ forwarded 
2 0 the same way as the previous messages. When node 40 

receives the split-point reduce message SPR(41) identi- 
fying its output port 41, it knows that port 41 is part 
of the new loop. Node 40 then sends out a release branch 
message RB on the remaining output port 43. As node 50 

2 5 and 60 then receive the release branch message RB, they 

cease to be build-up slaves and may start searching for 
other loops. Directly after sending the split-point 
reduce message SPR(41) , the build-up master 10 sends out 
a new split-point announce message (not shown) . As the 
30 split point at node 40 has now been resolved, the new 
split point announce message will be forwarded all the 
way back to the master node 10. The master node 10 will 
therefore determine that there are no more split-points 
in the loop. 

3 5 An example of the loop list build-up step of the 

topology discovery algorithm according to the preferred 
embodiment of the invention will now be described with 
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reference to Fig. 5. During the loop list build-up phase, 
the build-up master collects information about which 
nodes, and ports thereof, that are part of the new loop 
using message forwarding. The build-up master initiates 
5 the loop list build-up step by sending out an empty loop 
list (LB in Fig. 6) on the output port for the new loop. 
Each build-up slave on the loop path to the build-up 
master's input port adds itself to the loop list and for- 
wards the new loop list to the next node. When the loop 

10 list reaches the build-up master again, the build-up mas- 
ter adds itself to the end of the loop list. The loop 
list build-up phase is now finished and the build-up mas- 
ter has complete knowledge of the topology of the loop. 
It can then move on to the loop list distribution step. 

15 During the loop list distributing step, the build-up 

master informs all the nodes forming part of the new loop 
about the topology of the loop using message forwarding. 
The same message format is used to distribute the list as 
was used during the loop list build-up phase. The build- 

2 0 up master transmits the list LD on the output port where 

the new loop has been established. Each build-up slave 
node that receives a loop list under distribution must 
forward the list to the output port belonging to the same 
loop that the list arrived on. The build-up master that 

25 has originated the loop list must make sure that the list 
comes back via the input port belonging to the same loop 
as the output port that the list was originated on. If 
the loop list does not arrive within a configured time 
interval, or if an error is detected by a node during the 

30 loop list distribution, the list is re-originated. 

When the build-up master has received the full and 
correct loop list as transmitted, it will cease to ope- 
rate as build-up master, consider the new loop to be up 
and the loop state fully built. Correspondingly, when a 

3 5 build-up slave has received the full and correct loop 

list, it will cease to operate as a build-up slave, con- 
sider the loop to be up and the loop state fully built. 
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The (newly ceased) build-up master and slaves then con- 
tinue to the routing table computation step. 

In the routing table computation step, when a node 
has received and accepted a new loop list, it will use it 
5 to compute an updated route table based on the available 
loops considered valid. The route table will contain one 
item for each reachable node. Each item typically 
contains the output port that must be used to reach the 
destination and the MAC address of the input interface of 

10 the destination. 

For example, according to an alternative embodiment, 
the loop detection step, the split-point-reduction step, 
and the loop list build-up step is integrated into one 
single step, wherein the rules for handling a loop detec- 

15 tion message will include the split-point and loop list 
build-up features. An advantage of such a scheme is that 
it limits the amount of messages transmitted between the 
nodes of the network. On the other hand, it increases 
message size and processing. 

2 0 A flow chart of a topology discovery process accor- 

ding to another embodiment of the invention will now be 
described with reference to Fig. 6. As is understood, the 
main object of this topology discovery algorithm is to 
determine the existence of valid connections /link by 

25 detecting network loops of the kind indicated in Figs. 

la-lc and to provide information related thereto to one 
or more nodes that form part of the respective link. 

With reference to Fig. 6, the topology discovery 
algorithm comprises a loop detection step S110, a link 

30 announce step S120, a link list distribution step S130, 

and a route table computation step S140. The process will 
now be described in detali with reference to an exempli- 
fying network illustrated in Figs. 7a-7c, said network 
comprising three nodes 10, 20, and 30, interconnected to 

3 5 form a dual bus link, i.e. in similar to the network 

described above with reference to Fig. la. The descrip- 
tion will in this case exemplify topology determining 



WO 00/31925 



19 



PCT/SE99/02169 



actions taken by the nodes in the network, each action 
being discribed in relation to the event that causes the 
action. Typically, the actions described below will be 
decided upon by one or more control functions in each 
5 node . 

In the loop detection step S110 of Fig. 6, each node 
will regularly transmit so-called probe messages on all 
output ports for which no valid connections exists. Each 
probe message will be provided with a Link Identifier 

10 identifying the output port that the message is trans- 
mitted from, for example using the unique MAC address of 
the port, thus indirectly identifying the link that the 
message is transmitted on. This is illustrated by the 
probe message PR (11) in Fig. 7a, including an identifica- 

15 tion of the output port 11 that it is transmitted from. 

The purpose of a probe message is to find out if a valid 
connection has been established for the output port that 
the probe message is transmitted from. A probe message is 
in this embodiment only sent to neighbor nodes and is not 

2 0 as such forwarded to reach other nodes. The reason for 

this is that, in this embodiment, the topology discovery 
is based upon having each node discover its downstream 
neighbor. However, the scheme could just as well be modi- 
fied to let each node discover nodes further downstream, 
25 by for example allowing the probe message as such to be 
forwarded one or more hops . 

When a node receives a probe message, it will reply 
thereto by transmitting probe replies on all it's output 
ports. For each probe reply, it will include the Link 

3 0 Identifier of the probe message as well as a Reply Port 

Identifier identifying the output port that the probe 
reply message is transmitted from. This is illustrated in 
Fig. 7a by the two replies PRR(11:21) and PRR(11:23) that 
node 20 tranmits as a result of having received the probe 
3 5 message PR (11) , each reply including the identification . 
(11) identifying the probe message as well as an identi- 
fication (21 and 23) of the respective output ports 21 
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and 23 on which the reply is sent. For the probe reply 
that is transmitted from the output port that forms part 
of the same interface as the input port at which the 
probe message was received, include a flag identifying 
5 the reply as being sent in so-called "bypass mode" . The 
reason for including this flag will be described below. 
The reason for transmitting probe replies on all output 
ports is that the node has no way of telling in advance 
which one or more the output ports that provides a path 

10 back to the node that sent the probe message since 

several different topologies are allowed in the network. 

When a node receives a probe reply, it will first of 
all determine, using the Link Identifier included in the 
probe reply message, whether or not the probe reply is a 

15 reply to a probe message that the node itself has was the 
sender of, i.e. if the Link Idenifier included in the 
probe reply message identifies an output port of the 
node. If the answer e is no, the node will forward the 
probe reply on the output port of the same interface as 

2 0 it was received on. The reason for not forwarding the 
probe reply on all output ports in this embodiment, is 
that if the node itself wasn't the intended recipient, 
the path back to the intended recipient, given the allow- 
ed topologies, should be along the same unidirectional 

2 5 link that the message was received on. However, an embo- 

diment wherein the probe reply is forwarded on all output 
ports could also be used, but then some kind of mechanism 
would preferably be addedd to avoid messages from being 
forwarded forever within the network. 

3 0 If however the node determines, using the Link 

Identifier included in the probe reply, that the received 
probe reply is a reply to a probe message transmitted 
from an output port of the node, it will initiate the 
link announce step S12 0 of Fig. 6 by transmittin a link 
3 5 detected message, including the Link Identifier and the 
Reply Port Identifier of the probe reply (in this case 
port 23), from the output port identified by the Link 
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Identifier, i.e. the port that the probe message was 
originally transmitted from. This is illustrated in Fig. 
7b by the originating node 10 sending a link detection 
message LD(11:23) on the same port as it previously sent 
the probe message PR (11) on. Also, if the answere is yes 
and the probe reply includes a flag identifying the reply 
as being sent in so-called "bypass mode", the node will 
include, in the link detected message, a flag identifying 
that the receiver shall not originate a link toplogy 
message, the reason for which being described below. 

When a node receives a link detected message it 
will: a) conclude that a valid connection/link exists 
from an upstream node to the input port at which the link 
detected message is received; b) conclude that the up- 
stream neighbor node identifies its ouput port for this 
link using the Link Identifier included in the link 
detected message; c) determine, using the Reply Port 
Identifier included in the link detected message, which 
output port, referred to below as reply port, that shall 
be used when sending control messages to the upstream 
neighbor node regarding the the connection/link; e) 
transmit a link detected acknowledgement message from the 
reply port to reach the upstream neighbor node," said link 
detected acknowledgement message including the Link 
Identifier, as illustrated by the message ACK(ll) in Fig. 
7b. Furthermore, if the link detected message does not 
include a flag identifying that the receiver shall not 
originate a link toplogy message, it will transmit (ori- 
ginate) a link topology message from the reply port to 
the upstream neigbor node on the link, said link topology 
message including i) the Link Identifier, ii) the stored 
list of nodes that, as far as the node is aware, are 
connected to the link identified by the Link Identifier, 
and iii) a flag designating the list to be an upstream 
distributed list. This is illustrated in Fig. 7c by the 
link topology messgae LT(11:20,30) transmitted by node 20 
to node 10 using the determined reply port 23 and illu- 
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strates the link distribution step S130 of Fig. 6. Conse- 
quently, the reception of the link detected message 
informs a node that there now exists a link, comprising 
one or more node, upstreams from the input port on which 
5 the message is received. To provide the upstreams nodes 
with any existing information that the node has regarding 
itself and possible other downstream nodes, it sends the 
link topology message in the upstream direction using the 
reply port. For example, if the link segment 20-30 

10 between node 2 0 and 30 existed prior to the establishment 
of the connection between node 10 and 20, node will, 
after receiving the link detected message regarding the 
new connection 10-20 send the node list 2 0-30 upstreams, 
thereby informating upstream nodes on the known topology 

15 downstream of the new connection. 

Similarily, when the original sender of the probem 
essage receives the link detected acknowledgement message 
sent out from the reply port of the downstream node, it 
will conclude that a valid connection exists from the 

20 output port identified by the Link Identifier included in 
the link detected acknowledgement message. To inform 
downstream nodes now accessable via the new connection on 
the known topology upstream of the new connection, it 
will transmit (originate) a link topology message from 

2 5 said output port to the downstream neigbor node on the 

link, said link topology message including i) the Link 
Identifier, ii) the stored list of nodes that, as far as 
the originating node is aware, are connected to the link 
identified by the Link Identifier, and iii) a flag desig- 

3 0 nating the list to be a downstream distributed list. This 

is illustrated in Fig. 7b by the message LT(11:10) that 
is transmitted from node 10 to node 20 Consequently, 
returning to the example above, if the link segment 20-30 
existed prior to the establishment of the connection 10- 
35 20, node 10 will, after receiving the link detected 

message regarding the new connection 10-2 0 send the node 
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list 10 downstreams, thereby informing downstream nodes 
on the known topology upstream of the new connection. 

The purpose of the link topology messages is that 
they shall be forwarded in the downstream/upstream direc- 
5 tion, to be used to update each node on the link on the 
new topology. To be noted, if the newly established/- 
detected connection closes a single ring link, there is 
no need to send link topology messages both downstream 
along the link and upstream using the reply ports, as the 

10 downstream message will very efficiently be forwarded to 
all nodes on the link, and that is the reason for inclu- 
ding the above mentioned flag for "bypass" (in the probe 
reply) and the corresponding flag in the link detected 
message, thereby instructing the receiver of the link 

15 detected message not to transmit (originate) , as descri- 
bed above, any link topology message upstreams. 

Consequently, when receiving a link topology 
message, a node will determine whether or not it provides 
new information on the topology of the link identified by 

2 0 the Link Identifier included in the message as compared 

to topology information already stored at the node. If 
the answere is yes, the node will update the stored list 
designating nodes connected to the link accordingly. 
Also, if the answere is yes and the flag provided in the 

25 link topology message defines it as being a downstream 

distributed list, it will transmit a similar link topolo- 
gy message on the output port belonging to the same 
interface as the input port on which the link distributed 
message was received, and it will include therein i) the 

30 Link Identifier identifying said output port, ii) the 
updated list of nodes, and iii) a flag designating the 
list to be a downstream distributed list. Returning to 
the example mentioned above, when node 2 0 receives the 
downstream topology message from node 10 identifying the 

3 5 topology (10) known to node 10, node C will be updated on 

that the entire known link now comprises nodes 10, 2 0 and 
3 0 (the existence of node 30 was assumed already known to 
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node 20) , and will transmit a link topology message with 
this topology information (10-20-3 0) to its downstream 
neighbor node 30, as is illustrated by the messag LT 
(21:10,20,30) . 

5 Alternatively, if the received topology information 

is new and the flag provided in the link topology message 
defines it as being an upstream distributed list, the 
node will transmit a similar link topology message on the 
reply port to the upstream neighbor node and include 

10 therein i) the Link Identifier used by the upstream 

neighbor node to identify the port /link to the origina- 
ting node, ii) the updated list of nodes, and iii) a flag 
designating the list to be an upstream distributed list. 
However, if a received link topology message does 

15 not provide new information as compared to topology 
information already stored at the node, it will not 
transmit any correspoingin link topology message, thereby 
stopping the new link topology information/message from 
possibly circulating forever in a ring/loop. 

2 0 To be noted, in alternative embodiment, the topology 

information distributed in downstream/upstream topology 
messages could, as an alternative or addition to informa- 
tion explicitly identifyhing nodes, include information 
identifying interfaces, ports, or the like, identifying 

25 the topology of the link. It could also include informa- 
tion on the topology of other links that the one prima- 
rily addressed. 

Moreover, each node will regularly transmit verify 
messages (not shown) on all output ports for which valid 

30 connections exists. Each probe message verify message 

will be provided with a Link Identifier identifying the 
output port that the message is transmitted from. The 
purpose of a verify message is to verify that a connec- 
tion that has already been determined valid still exists 

3 5 from the port that the verify message is transmitted 

from. When receiving a verify message, a node will trans- 
mit a verify acknowledgement message on the reply port 
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associated with the Link Identifier included in the 
verify message. The upstream node will expect to receive 
the verify acknowledgement message within a certain 
period of time. If the message isn't received wihtin this 
5 period of time, it will determine the connection to no 
longer be valid, and will therefore originate a new. link 
topology message in the upstream direction (using the 
reply port to its upstream neighbor node) to inform 
upstream nodes on the link at issue on the missing 

10 connection. Similarily, each node having an upstream 

neighbor will expect to receive a verify message regula- 
rly. If a new verify message isn't received within a 
certain period of time, it will determine the connection 
to the upstream node to no longer be valid, and will 

15 therefore originate a new link topology message in the 
downstream direction of the link at issue to inform 
downstream nodes on the missing connection. 

Fig. 7 is a block diagram exemplifying general 
components of a node used in the networks discussed 

20 above. The node comprises a first interface defined by 
output port 111 and input port 112, as well as a second 
interface defined by output port 113 and input port 114. 
The two interfaces are connected to a switch core 115 
that provides switching of data between the interfaces as 

25 well as to/from the interfaces and a control processor 

116 of the node. Furthermore, each intefaces as such will 
typically also be provided with means for bypassing/ - 
switching data from its own input port to its own output 
port. The control processor typically provides the above 

3 0 mentioned control function that handles tranmitted and 
received messages of the kind described above, and uses 
information in the message to update a memory 117 that 
stores topology information. Note, however, that such a 
control function and memory need not be centralized 

3 5 within the node, handling topology discovery operation 
with respect to all interfaces of the node. The control 
fucntion and/or memory storage could just as be implemen- 
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ted a several parallel control functions, each for 
example operating in relateion to a respective interface 
of the node. 

Finally, Figs. 8b and 8c illustrates entries of the 
5 kind found in the memory 117 of Fig 8a, exemplified with 
the content as found in node 10 and node 20, respect ivly, 
after having determined the existence of the connection 
that is discussed with reference to Figs. 7a-7c. As is 
illustrated, after the new connection from port 11 to 

10 port 22 has been detected and topology information per- 
taining therego has been distributed, the memory of node 
10, illustrated in Fig. 8b, indicates that the link to 
which port 11 (link ID) is connected comprises nodes 10, 
20 and 30. As node 10 itself is the most upstream node on 

15 the link, no reply port exist to any upstream node. 

Similarily, the memory of node 20, illustrated in Fig. 
8c, indicates that the link to which its port 21 is 
connected comprises nodes 10, 20 and 30, and that node 2 0 
can use its port 23 as reply port to reach its upstream 

2 0 neighbor node 10. 

As understood by those skilled in the art, the above 
mentioned steps may be altered, modified, and/or integra- 
ted. Furthermore, steps may be added or excluded based 
upon the desired functionality within the scope of the 

2 5 invention, which is defined by the accompanying claims. 

Based upon the inventive idea, many diffenet topo- 
logy message handling rules may be used, for example 
deteriming how and when to send probe messages, how and 
when to look for new connections, and so on, the scope of 

3 0 the invention of couse not being limited to the specific 

embodiment described in detail above. 

Hence, the decision regarding how to actually rea- 
lize and implement the invention will typically depend 
upon how the explicit network type will be positively or 
3 5 negatively affected by aspects such as the amount of 

messages transmitted within the network, message size, 
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the amount of message processing, the changing and/or 
maintaining of states at each node, and so on. 
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1 . A method for determining the topology of a net- 
work of nodes that are interconnected via unidirectional 
connections, said method comprising the steps of: 

determining the existence of a network loop within 
said network using message forwarding among said nodes; 
and 

distributing information related to the existence of 
said network loop within said network. 

2. A method as claimed in claim 1, wherein said step 
of determining the existence of a network loop comprises 
the steps of: 

transmitting a message from an output port of a 
first node; and 

receiving a forwarded/reply version of said message 
at an input port of said first node. 

3 . A method as claimed in claims 1 or 2 , wherein 
said step of determining the existence of a network loop 
comprises the steps of receiving a message at an input 
port of a node and forwarding said message on one or more 
output ports thereof . 

4. A method as claimed in any one of the preceding 
claims, wherein said step of distributing information on 
the existence of said network loop comprises using 
message forwarding for distributing said information. 

5. A method as claimed in any one of the preceding 
claims, wherein said information comprises information as 
to which nodes that form part of said network loop. 

6. A method as claimed in any one of the preceding 
claims, wherein said information comprises information as 
to which ports that form part of said network loop. 
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7. A method as claimed in any one of the preceding 
claims, including the steps of: 

transmitting two or more messages from respective 
5 two or more output ports of a node, each message identi- 
fying the respective output port used for transmission 
thereof; and 

receiving a message referring to one of said two or 
more messages, thereby identifying which one of said two 
10 or more output ports of said node that forms part of said 
network loop . 

8 . A method as claimed in any one of the preceding 
claims, including the steps of: 

15 transmitting a message from an output port of a 

first node; 

receiving said message, as such or in a forwarded 
version, at an input port of a second node; 

transmitting two or more modified versions of said 
20 message from respective two or more output ports of said 
second node, each modified version identifying the 
respective output port used for transmission thereof; 

receiving one of said modified versions of said 
message at said first node, thereby identifying which one 
25 of said two or more output ports that forms part of said 
network loop; and 

transmitting a message from said first node to said 
second node, said message identifying the output port of 
said second node that forms part of said network loop. 

30 

9 . A method as claimed in any one of the preceding 
claims, wherein forwarding a message comprises the step 
of including information as to the identity of the 
forwarding node into said message. 

35 

10. A method as claimed in any one of the preceding 
claims, wherein forwarding a message comprises the step 
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of including information as to the identity of the output 
port that said message is transmitted from into said 
message . 

11. A system for determining the topology of a net- 
work of nodes that are interconnected via unidirectional 
connections, comprising a first node that is arranged to 
transmit a message from an output port thereof, to deter- 
mine the existence of a network loop within said network 
by determining reception of a forwarded/ reply version of 
said message at an input port thereof, and, as a result, 
to distribute information related to the existence of 
said network loop to nodes within said network. 

12. A system as claimed in claim 11, comprising one 
or more second nodes being arranged to forward said 
message on one or more output ports thereof when 
receiving said message on an input port thereof . 

13. A system as claimed in claims 11 or 12, wherein 
said nodes are arranged to distribute said information on 
the existence of said network loop by message forwarding. 

14. A system as claimed in any one of claims 11-13, 
wherein a node that has two or more outgoing ports is 
arranged to transmit two or more respective messages from 
respective output ports, each message identifying the 
respective output port used for transmission thereof and 
thereby enabling subsequent determination of which one of 
said two or more output ports of said node that forms 
part of said network loop. 

15. A system as claimed in any one of claims 11-14, 
comprising : 

a first node transmitting a first message; 
a second node receiving said message, as such or in 
a forwarded version, and transmitting two or more 
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modified versions of said message from respective two or 
more output ports, each modified version identifying the 
respective output port used for transmission thereof, 
wherein said first node is arranged to identify 
5 which one of said two or more output ports, of said 
second node, that forms part of said network loop by 
determining reception of one of said modified versions of 
said message at said first node, and, as a result, to 
transmit a message from said first node to said second 
10 node, said message identifying the output port of said 
second node that forms part of said network loop. 

16. A method for determining a reconf igurable topo- 
logy, at least locally, of nodes in a communication 

15 network, each node comprising one or more interfaces, 
each interface being defined by an input port and an 
output port connectable to other nodes via unidirectional 
connections, a node directly connected to another node 
via a unidirectional connection herein being referred to 

20 as a neighbor node, said method comprising the steps of: 
transmitting probe messages from output ports of an 
originating node, each probe message being provided with 
information identifying the output port that it is trans- 
mitted from; 

25 receiving probe replies at input ports of the origi- 

nating node, each probe reply including information iden- 
tifying a probe message that the probe reply is a reply 
to as well as information identifying the probe reply; 
and 

30 determining if a valid connection exists from an 

output port of the originating node to a neighbor node by 
determining if a received probe reply identifies a probe 
message that has previously been sent from an output port 
of the originating node and if so causing transmission of 

3 5 a link detected message from said output port, said link 
detected message being provided with information identi- 
fying the probe reply, thereby acknowledging to the 
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neighbor node that said connection exists and, by the 
provision of said information identifying the probe 
reply, making it possible for said neighbor node to 
determine which of its output ports that it may use for 
5 sending information to the originating node regarding 
said connection. 

17. A method as claimed in claim 16, wherein any two 
unidirectional connections connected to the same inter- 
10 face herein being considered to form part of the same 
link, said method further comprising the steps of: 

storing, for each interface of said originating 
node, topology information identifying nodes that, as far 
as the originating node is aware, are connected to the 
15 same link as said interface; and 

transmitting, if having determined that a new valid 
connection exists from an output port of the originating 
node to another node, a link topology message from said 
output port, said link topology message being provided 
2 0 with information identifying said connection as well as 
topology information identifying nodes that, as far as 
the originating node is aware, are connnected to the link 
that said connection forms part of . 

25 18 . A method as claimed in claim 16 or 17, further 

comprising the step of forwarding a received probe reply 
to other nodes if the probe reply is determined not to 
identify a probe message that has previously been sent 
from an output port of the originating node. 



19. A method as claimed in claim 18, wherein, if a 
received probe reply is determined not to identify a 
probe message that has previously been sent from an 
output port of the originating node, said probe reply is 
3 5 forwarded only on the output port that is part of the 

same interface as the input port at which the probe reply 
was received. 
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20. A method as claimed in claim 16, 17, 18, or 19, 
wherein said probe messages are sent from the originating 
node to its neighbor nodes only. 

5 

21. A method as claimed in claim 16, 17, 18, 19, or 
20, further comprising the steps of: 

receiving probe messages at input ports of the node, 
each probe message including information identifying the 
10 probe message; and 

transmitting, for each received probe message, probe 
replies on all output ports of the node, each probe reply 
including said information identifying the probe message 
as well as information identifying the output port that 
15 the probe reply is sent from. 

22. A method as claimed in claim 21, wherein said 
step of transmitting a probe reply on all output ports 
for each received probe message comprises including, in 

2 0 the probe reply sent on the output port that is part of 

the same interface as the input port at which said probe 
message was received, information identifying that the 
probe reply is transmitted from the same interface as the 
probe message was received at. 

25 

23. A method as claimed in claim 21 or 22, further 
comprising the steps of: 

receiving link detected messages at input ports of 
the node, each including information identifying an 

3 0 output port that the probe reply that caused the sending 

of the link detected message was sent from; 

determining that a valid connection exists from a 
neighbor node to the input port that the link detected 
message is received at, including storing information 
3 5 designating that said output port identified in the link 
detected message may be used for sending information to 
the neighbor node regarding said connection. 
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24. A method as claimed in claim 23, wherein any two 
unidirectional connections connected to the same inter- 
face herein being considered to form part of the same 

5 link, said method further comprising the steps of: 

storing, for each interface of said originating 
node, topology information identifying nodes that, as far 
as the originating node is aware, are connected to the 
same link as said interface; and 

10 transmitting, when having determined that a valid 

connection exists from a neighbor node to an input port 
that a link detected massage is received at, a link 
topology message from the output port identified in said 
link detected message, said link topology message inclu- 

15 ding information identifying which connection that the 
topology message pertains to as well as topology infor- 
mation identifying nodes that, as far as the originating 
node is aware, are connnected to the link that said 
connection forms part of. 

20 

25. A method as claimed in claim 24, wherein said 
step of transmitting a link topology message when having 
determined that a valid connection exists from a neighbor 
node to an input port that a link detected massage is 

25 received at is performed only if said link detected 

message does not indicate that no link topology message 
shall be sent as a result of the received link detected 
message . 

30 26. A method for locally distributing topology 

information among nodes in a communication network, each 
node comprising one or more interfaces, each interface 
being defined by an input port and an output port 
connectable to other nodes via unidirectional connec- 

35 tions, any two unidirectional connections connected to 
the same interface herein being considered to form part 
of the same link, a node directly connected to another 
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node via a unidirectional connection herein being 
referred to as a neighbor node, said method comprising 
the steps of: 

storing, for each interface of a node, topology 
5 information identifying nodes that, as far as the node is 
aware, are connected to the same link as the interface as 
well as information identifying a suggested output port 
of the node to be used for sending topology information 
to an upstream neighbor node on said link; 

10 receiving link topology messages at input ports of 

the node, each message including information identifying 
the link that it pertains to as well as topology infor- 
mation identifying nodes connnected to said link; 

updating, for each received link topology message, 

15 stored topology information in accordence with topology 
information provided by the received link topology 
message; and 

transmitting, for each received link topology mes- 
sage, a link topology message from the output port of the 
2 0 interface at which the received link topology message was 
received if the received link topology message was sent 
by an upstream neighbor node on the link that the recei- 
ved link topology message refers to, or, if the received 
topology message was sent by a downstream neighbor node 

2 5 on the said link, from said suggested output port to be 

used for sending topology information to the upstream 
neighbor node on said link, the transmitted topology 
message including information identifying the link that 
it pertains to as well as topology information identify- 

3 0 ing nodes that, as far as the node is aware, are connec- 

ted to said link. 

27. A method as claimed in claims 26, wherein said 
updating step is performed only if the topology informa- 
35 tion provided in the received topology message is new as 
compared to already stored topology information regarding 
the link that the topology message pertains to. 
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28. A method as claimed in claim 26 or 26, wherein 
said transmitting step is performed only if the received 
link topology message provides topology information that 

5 is new as compared to already stored topology information 
regarding the link that the topology message pertains to. 

29. A method as claimed in claim 26, 27 or 28, 
wherein topology information included in the link 

10 topology message that is transmitted in said transmitting 
step is selected so as to reflect the accumulated 
topology information provided by the received link 
toplogy message and the topology information stored with 
respect to the subject link prior to the reception of the 

15 received link toplology message. 

30. A system for determining a reconf igurable topo- 
logy, at least locally, of nodes in a communication net- 
work, each node comprising one or more interfaces, each 

2 0 interface being defined by an input port and an output 
port connectable to other nodes via unidirectional con- 
nections, a node directly connected to another node via a 
unidirectional connection herein being referred to as a 
neighbor node, an originating node further comprising: 

2 5 transmitter means for transmitting probe messages 

from output ports of the originating node, each probe 
message being provided with information identifying the 
output port that it is transmitted from; 

receiver means for receiving probe replies at input 

•3 0 ports of the originating node, each probe reply including 
information identifying a probe message that the probe 
reply is a reply to as well as information identifying 
the probe reply; and 

logic means for determining if a valid connection 

35 exists from an output port of the originating node to a 
neighbor node by determining if a received probe reply 
identifies a probe message that has previously been sent 
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from an output port of the originating node and if so 
causing transmission of a link detected message from said 
output port, said link detected message being provided 
with information identifying the probe reply, thereby 
5 acknowledging to the neighbor node that said connection 
exists and, by the provision of said information identi- 
fying the probe reply, making it possible for said 
neighbor node to determine which of its output ports that 
it may use for sending information to the originating 
10 node regarding said connection. 

31. A system as claimed in claim 30, wherein any two 
unidirectional connections connected to the same inter- 
face herein being considered to form part of the same 
15 link, said method further comprising: 

memory means for storing, for each interface of said 
originating node, topology information identifying nodes 
that, as far as the originating node is aware, are 
connected to the same link as the interface, 

2 0 said logic means, if having determined that a valid 

connection exists from an output port of the originating 
node to another node, being arranged to cause transmis- 
sion of a link topology message from said output port, 
said link topology message being provided with informa- 
25 tion identifying said connection as well as topology 

information identifying nodes that, as far as the origi- 
nating node is aware, are connnected to the link that 
said connection forms part of. 

30 32. A system as claimed in claim 30 or 31, said 

logic means, if determining that a receiced probe reply 
does not identify a probe message that has previously 
been transmitted from an output port of the originating 
node, being arranged to cause forwarding of the probe 

3 5 reply to other nodes. 
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33. A system as claimed in claim 32, said logic 
means, if determining that a received probe reply does 
not identify a probe message that has previously been 
sent from an output port of the originating node, being 

5 arranged to cause forwarding of said probe reply only on 
the output port that forms part of the same interface as 
the input port at which the probe reply was received. 

34. A system as claimed in claim 30, 31, 32, or 33, 
10 wherein said probe messages are transmitted from the 

originating node to its neighbor nodes only. 

35. A system as claimed in claim 30, 31, 32, 33, or 
34, said logic means being arranged, when a probe message 

15 has been received at an input port of the node, said 

probe message including information identifying the probe 
message, to cause transmission of a probe reply on each 
output port of the node, each probe reply being provided 
with said information identifying the probe message as 

2 0 well as information identifying the output port that the 
probe reply is transmitted from. 

36. A system as claimed in claim 35, said logic 
means being arranged, when a link detected message has 

2 5 been received at an input port of the node, said message 

including information identifying an output port that the 
probe reply that caused the sending of the link detected 
message was sent from, to determine that a valid connec- 
tion exists from a neighbor node to the input port that 

3 0 the link detected message was received at and to cause 

storing, in said memory means, of information designating 
that said output port identified in said link detected 
message may be used for sending information to the 
neighbor node regarding said connection. 



37. A system as claimed in claim 36, wherein any two 
unidirectional connections connected to the same inter- 
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face herein being considered to form part of the same 
link, said logic means geing arranged, when having 
determined that a new valid connection exists from a 
neighbor node to an input port that a link detected 
5 massage was received at, to cause transmission of a link 
topology message from the output port identified in said 
link detected message, said link topology message inclu- 
ding information identifying said connection as well as 
topology information identifying nodes that, as far as 
10 the originating node is aware, are connnected to the link 
that said connection forms part of. 

38. A system for locally distributing topology 
information among nodes in a communication network, each 
15 node comprising one or more interfaces, each interface 
being defined by an input port and an output port 
connectable to other nodes via unidirectional connec- 
tions, any two unidirectional connections connected to 
the same interface herein being considered to form part 

2 0 of the same link, a node directly connected to another 

node via a unidirectional connection herein being 
referred to as a neighbor node, a node comprising: 

memory means for storing, for each interface of a 
node, topology information identifying nodes that, as far 

25 as the node is aware, are connected to the same link as 
the interface as well as information identifying a 
suggested output port of the node that the node may use 
for sending topology information to an upstream neighbor 
node on said link; 

30 receiver means for receiving link topology messages 

at input ports of the node, each message including 
information identifying the link that it pertains to as 
well as topology information identifying nodes connnected 
to said link; 

3 5 transmitter means for transmitting link topology 

messages from output ports of the node, each message 
including information identifying the link that it 
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pertains to as well as topology information identifying 
nodes that, as far as then node is aware, are connnected 
to said link; 

logic means for updating topology information stored 
5 in said memory means in accordence with topology informa- 
tion provided by received link topology messages and for 
causing, for each received link topology message, trans- 
mission of a link topology message from the output port 
of the interface at which the received link topology mes- 

10 sage was received if the received link topology message 
was sent by an upstream neighbor node on the link that 
the received link topology message refers to, or, if the 
received topology message was sent by a downstream neigh- 
bor node on said link, from said suggested output port to 

15 be used for sending topology information to the upstream 
neighbor node on said link. 

39. A system as claimed in claims 38, said logic 
means being arranged to update topology information 

20 stored in said memory menas only if topology information 
provided in received topology messages is new as compared 
to already stored topology information. 

40. A system as claimed in claim 38 or 39, said 

2 5 logic means being arranged to cause said transmission of 
a link topology message only if the received link topo- 
logy message provides topology information that is new as 
compared to already stored topology information regarding 
the link that the topology message pertains to. 

30 

41. A system as claimed in claim 38, 39, or 40, said 
logic means being arranged to select topology information 
to be included in a topology message to be transmitted 
from said node as a result of the reception of a link 

35 topology message so as to reflect the accumulated topo- 
logy information provided by the received link toplogy 
message and topology information already stored with 
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respect to the subject link prior to the reception of the 
received link toplology message. 
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